
Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



llllllllllllllllllllllifi 



(11) EP 0 778 535 A2 



(12) 



EUROPEAN PATENT APPLICATION 



(43) 



Date of publication: 
11.06.1997 Bulletin 1997/24 



(51) Int. CI. 6 : G06F 17/60 



(21) 



Application number: 96308763.0 



(22) 



Date of filing: 04.12.1996 



(84) 



Designated Contracting States: 
DE FR GB IT NL 



(72) 



Inventor: Gadoi, Steven D. 
Portola Valley, California (US) 



(30) 



Priority: 08.12.1995 US 569801 



(74) 



Representative: Cross, Rupert Edward Blount et 
al 

BOULTWADE TENNANT 
27 Furnival Street 
London EC4A1PQ(GB) 



(71) 



Applicant: SUN MICROSYSTEMS, INC. 
Mountain View, California 94043-1 100 (US) 



(54) Distributed asynchronous workflow system and method 

(57) A system and method for automating workflow 
by distributing the tasks required for the execution of 
said workflow over servers and clients connected on a 
network. The disclosed system and method allow the 
stages of the workflow to be performed asynchronously, 
meaning that, once a workflow initiated by a user has 
been initiated by a database server, the stages of the 
workflow can be executed on respective network clients 
without further interaction with the server (i.e., without 
requiring a stateful connection between the clients and 
servers). This is accomplished through the use of a 
workflow courier that embodies all programs (encom- 
passing rules governing the execution of the workflow) 
and forms needed by clients to complete stages of the 
workflow. The workflow courier also stores workflow 
state information that indicates which stages of the 
workflow have been completed. The executable pro- 
grams are written in the platform-independent Java pro- 
gramming language and are therefore executable on 
any computer that has an installed Java browser. After 
each stage is executed, the client executing that stage 
updates the workflow courier and transmits the updated 
workflow courier to a client having an associated user 
who is authorized to perform the next step in the work- 
flow. The updated state information indicates to the 
recipient of the workflow which stages remain to be 
completed. 
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Description 

The present invention relates generally to computer 
networks and, particularly, to methods and systems for 
performing a sequential process, or workflow, on distrib- 
uted nodes of a network without requiring the network 
nodes to have prior knowledge of the sequential proc- 
ess being performed or to share a stateful connection. 

BACKGROUND OF THE INVENTION 

In business settings, many projects or tasks are 
performed in stages, where each stage of the task is 
performed by a different person and where the stages 
are performed in an order that is dictated by a set of 
business rules. These kinds of tasks are called a work- 
flow. One such workflow is the corporate travel 
request/reimbursement process where, prior to taking a 
business trip, an employee might be required to submit 
a travel request to his manager for approval. Once 
approval is granted, a corporate travel department could 
then be asked to make appropriate travel arrangements, 
after which the employee is free to make the trip. After 
returning from the trip, in order to be reimbursed for his 
travel expenses the employee might need to complete 
and submit for his manager's approval a travel expense 
report. If the manager approves the expense report, it 
will be typically relayed to an appropriate person in the 
accounting department, who will authorize payment to 
the employee of the approved amount. If the manager 
rejects the expense report (perhaps the employee omit- 
ted a required signature or requested reimbursement for 
unauthorized expenses), the report might be bounced 
back to the employee for correction, then resubmitted to 
the manager. Thus, in this workflow, and in many others, 
there is typically some flexibility in the ordering of the 
workflow stages. 

Note also that there is likely to be some flexibility in 
the actors who are authorized by the rules to perform 
each of the stages. For example, in the travel expense 
case, corporate rules might allow the employee's man- 
ager to approve for reimbursement expenses below one 
thousand dollars, but those same rules might require 
approval by the manager and the manager's manager 
for larger amounts. These workflow traits suggest a 
need for dynamic routing among workflow actors in sys- 
tems that automate workflows. 

Traditionally, workflow has been automated using 
architectures similar to the one shown in Figure 1. In 
this type of automated workflow system, an individual 
(e.g., the traveling employee) uses a client workstation 
with some stateful connection to a server to initiate a 
workflow request. In response, the server initiates a 
workflow application, which causes the server to return 
a form (e.g., the travel request document) to the client 
for the requestor to fill out. Once the requestor has com- 
pleted the form, he sends it back to the server, which, 
under control of the same workflow application, stores 
in a database the information entered by the requestor. 



The workflow application then uses the information in 
the database to send the same form or a related form 
(e.g., a travel approval form) to an actor (e.g., the 
traveling employee's manager) who is authorized to per- 

5 form the next stage of the workflow. The workflow appli- 
cation might consult an organizational database to 
identify the manager of the requestor. Once the author- 
ized actor completes the next stage (e.g., approves the 
travel request), the form is returned to the server, where 

1 o the workflow application updates the database and car- 
ries out additional transmissions (actions) to complete 
the remaining stages of the workflow. For example, after 
receiving the completed travel approval form, the work- 
flow application might forward both forms to the corpo- 

15 rate travel office to make travel arrangements. 
Automated workflow processes also typically check for 
required items such as employee signatures and travel 
expenditure amounts. 

This type of traditional automated workflow system 

20 requires that compatible versions of all required soft- 
ware be pre-installed on the network nodes of all per- 
sons who might perform some stage of the workflow. 
These prior art systems also require that forms, code, 
business rules governing the execution of the workflow 

25 and storage of workflow data all be tightly coordinated. 
This is because all of the intelligence in such systems 
resides in the coordinated applications running on the 
network nodes and not in the forms transferred across 
the network, which are mere data containers. For exam- 

30 pie, if the server sent the requestor a form in a format 
which could not be read or processed by any software 
on the requestor's client, the requestor could not fill out 
the form and the workflow could not be completed. Con- 
sequently, if either the workflow application running on 

35 the server or the related programs that run on the 
employee's or manager's client workstations that allow 
a user to interact with the forms sent by the server are 
updated or modified, coordinated software updates 
must be performed across the entire system. This 

40 requirement for coordinated updates means that auto- 
mated systems of this type must be strongly centralized 
around a primary database server with stateful network 
connections to client nodes. Of course, the strongly 
centralized nature of this type of automated workflow 

45 system means that network bandwidth and computing 
resources are not efficiently utilized. Even more impor- 
tant, when such automated workflow systems are 
implemented on large networks, the cost of coordinating 
the many network nodes on which stages of the work- 
so flow are performed can become prohibitively large. This 
is because such large networks have many more failure 
modes than a single mainframe or server controlling 
dumb terminals or clients, which is the environment for 
which the prior automated workflow models were con- 

55 ceived. 

Consequently, there is a need for an improved 
workflow automation system that does not require pre- 
installation of all software required to execute a work- 
flow on the network nodes of all possible actors in that 
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workflow. There is also a need for a workflow automa- 
tion system that is not strongly centralized (i.e., more 
flexible, less complex, lower cost of operation than the 
prior art) and therefore makes efficient use of network 
bandwidth and computing resources. Finally, there is a 5 
need for a workflow automation system that does not 
require stateful connections between a single database 
server and the network nodes of actors who perform 
stages of the workflow. 

SUMMARY OF THE INVENTION 

In summary, the present invention is an improved 
workflow automation system that does not require pre- 
installation of all software required to execute a work- is 
flow on the network nodes of all possible actors in that 
workflow. The present invention also enables workflow 
automation tasks to be distributed across the network 
nodes, rather than being centralized in a server, which 
makes efficient use of network bandwidth and comput- 20 
ing resources. Finally, the workflow automation system 
of the present invention does not require stateful con- 
nections between a single database server and the net- 
work nodes of actors who perform stages of the 
workflow. 25 

More particularly, the present invention is a distrib- 
uted system for asynchronously executing steps of a 
sequential process on a network that includes at least 
one server and at least one client coupled to the net- 
work, wherein the servers and the clients each include 30 
a processor and a memory and have a unique network 
ID. This distributed system includes a requestor pro- 
gram that is executable on a client's processor, and a 
provider program that is executable on a server's proc- 
essor and a workflow courier which is passed from the 35 
provider to the requestor. 

The requestor is configured to control messages 
issued by the client on the network, one of which is a 
document request message instructing a particular one 
of the servers to transmit to the client a workflow courier 40 
requested by a user of the client. The provider, which is 
configured to be responsive to the messages directed to 
the server, responds to the provider's document request 
message by causing the server to transmit to the client 
the workflow courier. This workflow courier includes a 45 
set of forms to be completed through the execution of a 
plurality of stages that compose a workflow, each of the 
stages being executable by a respective actor. For the 
purposes of the present application, the term "forms" 
means any manifestation of a set of actions to be com- 50 
pleted through the execution of the workflow, including 
conventional forms. The workflow courier also includes 
state data indicating executed stages in the workflow 
and a registry containing at least one code fragment ref- 
erence, each of which points to an executable code 55 
fragment. 

Upon receiving the workflow courier document over 
the network, the requestor displays one of the forms 
and, based on user interaction with that form and other 



displayed forms, selectably loads and runs a set of ref- 
erenced code fragments that are configured, when run- 
ning, to perform a number of workflow tasks. For 
example, possible workflow tasks include displaying the 
forms, determining from the state data a pending stage 
to be executed, guiding an actor through execution of 
the pending stage based on workflow rules, updating 
the forms and the state data in the workflow courier doc- 
ument to reflect completion of the pending stage and 
forwarding the updated workflow courier document to 
an appropriate network node for execution of a subse- 
quent stage by another actor. </ 

BRIEF DESCRIPTION OF THE DRAWINGS 

Examples of the invention will be described in con- 
junction with the drawings, in which: 

Figure 1 is a diagram illustrating the architecture of 
prior art workflow processing environments. 

Figure 2 is a diagram illustrating a preferred embod- 
iment of an asynchronous distributed system for 
workflow as taught by the present invention. 

Figure 3 is a flow chart illustration the steps by 
which the embodiment asynchronously executes 
the stages of a workflow over a network. 

Figure 4 is a data structure-oriented diagram of the 
workflow courier of the embodiment. 

Figure 5 is a flow chart of the method by which a 
networked client completes one stage of a workflow 
using the workf bw courier. 

Figure 6 illustrates an example of the execution of 
one stage of a workflow. 

Figure 7 illustrates some alternative embodiments 
of the workflow courier of the present invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

SYSTEM ARCHITECTURE 

Referring to Figure 2, there is shown is a diagram 
illustrating a preferred embodiment 100 of an asynchro- 
nous distributed system for workflow as taught by the 
present invention. 

The preferred embodiment includes a network of 
servers 110-1, 110-2 and clients 112-1, 112-2, 112-3, 
each with a unique network address. At least one of the 
servers 1 10-1 is coupled to a workflow database 114-1, 
to which the server 110-1 can issue database queries. 
Another server 110-2 could be coupled to a user direc- 
tory 114-2, which is a database that lists the node 
addresses of clients 112 associated with known net- 
work users. Generally, these users interact with their 
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associated client 112 through a display/input device 
113. There is no requirement for commonality (of hard- 
ware or operating systems) among the servers 1 10 and 
clients 112 except that, as network nodes, they must be 
capable of communicating over the network linking 5 
them. For the purposes of the present invention, "com- 
municating" means any exchange of data with meaning 
to a computer, including e-mail, transfers over persistent 
network connections, dial-up access, or even sneaker- 
net transfers using floppy disks. As the network in the 10 
preferred embodiment is the Internet, the servers 110 
and clients 112 communicate using Internet protocols, 
such as TCP/IP or HTTP (hypertext transfer protocol), 
RPC (remote procedure calls) or SMTP (simple mail 
transport protocol).. In addition to being suited for use 15 
with the Internet, the present invention can be employed 
with other types of networks, such as departmental 
local area networks (LANs) or corporate wide area net- 
works (WANs). 

The workflow database 1 14-1 represents the forms 20 
142 and rules 146 associated with each workflow (WF) 
140-1, 140-2 that can be initiated by a user. Possible 
rules 1 46 include (1) what actor type must approve what 
requests (for the purposes of this document, the term 
"actor type" also encompasses other actor selection cri- 25 
teria), (2) the formatting of data fields in the forms 142, 
(3) what data fields must be completed before a stage is 
considered complete and (4) meta-rules that describe 
the workflow at a high level. The workflow database 
114-1 also includes code fragments 1 44 that, when exe- 30 
cuted on a client 112, assist the clients' user to com- 
plete a stage or stages of a particular workflow 140. For 
example, a code fragment 144 might be a handler for a 
form 1 42 written in a format that could not, without the 
handler, be displayed or manipulated by the clients 112. 35 
In the preferred embodiment, the code fragments 144 
are executables written in a platform-independent com' 
puter language, such as Java. 

Important features of the Java programming lan- 
guage include the architecture-independence of pro- 40 
grams written in the Java language, meaning that they 
can be executed on any computer platform having a 
Java interpreter, and the verifiability of the integrity of 
such programs, meaning that the integrity of Java pro- 
grams can be verified prior to their execution. A Java 45 
program verifier determines whether the program con- 
forms to predefined stack usage and data usage restric- 
tions that ensure that verified programs cannot overflow 
or underflow the executing computer's operand stack 
and that all program instructions utilize only data of so 
know data types. As a result, Java language programs 
cannot create object pointers and generally cannot 
access system resources other than those resources 
which the user explicitly grants it permission to use. 
Consequently, when one or more of the code fragments 55 
144 are downloaded to a client 1 12 along with an asso- 
ciated form 142, a Java-compatible browser 166 run- 
ning on the client 1 12 will be able to verify and execute 
the downloaded code fragments 144 and display and 



assist the user in filling out the associated forms. Of 
course, the present invention could also be imple- 
mented in a platform-specific manner in which each of 
the clients 1 12 has a known configuration and the pro- 
grams are designed to run on these clients. However, 
such an implementation would result in a significant loss 
of flexibility. Another useful feature of Java is that Java 
applications can be dynamically downloaded and 
installed on the client system. 

The servers 1 10-1 , 1 10-2 include a processor 120 
and a memory 122, which could be a fast memory, such 
as a random access memory (RAM), a slower second- 
ary memory, such as a hard disk, or both. Stored in 
each memory 122 is an operating system 124 that runs 
on the processor 110, a workflow courier 118 and a 
workflow agent 126. The workflow courier 118 is struc- 
tured similarly to an HTML (HyperText Markup Lan- 
guage) document and embodies all forms 128, state 
information 132, programs 130 and program references 
134 needed by the clients 112 to perform a stage or 
stages of a requested workflow. The workflow courier 
1 18 is formed dynamically by the workflow agent 126 in 
response to a workflow request 116 issued by one of 
the clients 1 12. The workflow agent 126 builds the work- 
flow courier 118 using information contained in the 
workflow database 114-1 that pertains to the requested 
workflow and, optionally, specific information on the 
requesting user that is included with the request 116. 

For example, if a user of the client 112-1 were to 
issue a travel request workflow message 116 and, 
assuming that the workflow database entry 140-1 is 
associated with the travel request workflow, the work- 
flow agent 126-1 would build the workflow courier 118 
from the forms 142-1. code fragments 144-1 and rules 
146-1. The workflow agent 126-1 might also make use 
of known information such as the requestor's network 
ID, department and the time and data of the request to 
fill-in some of the fields of the forms 142-1. This user 
information might be found in the message 1 16 from the 
requestor or in the user directory 114-2. In building the 
workflow courier 1 18, the workflow agent 126 encapsu- 
lates the code fragments 144-1 and rules 146-1 into 
Java programs 130-1, which can be thought of as uni- 
versally-executable expert systems encompassing 
knowledge about displaying and filling in the forms 128- 
1, and completing stages of the workflow 140-1. The 
forms 128-1 are created by the workflow agent 126-1 as 
copies of the forms 142-1. except that, where a hyper- 
link associated with a field of a form 142-1 references 
an absolute address (e.g., the URL, or universal 
resource locator) of the code fragment(s) associated 
with that field, the workflow agent 126-1 resets that 
hyperlink to the local address of an entry in the registry 
134-1 that contains the absolute address of the corre- 
sponding program 130-1. More will be said below about 
the registry 134-1 ; however, note that the registry 134-1 
stores the addresses, or names, of the programs 130-1 
that are embedded within the workflow courier 118-1 or 
stored in the memory 122 of another network node. 
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Access to the entries of the registry 134-1 are obtained 
through local pointers, which, through binding with indi- 
vidual registry entries, are resolved to meaningful net- 
work names (e.g.. actual program URLs) that are then 
used to retrieve the referenced programs. As for the 5 
accumulated state 132-1 , this is a data structure whose 
entries store information about completed stages in the 
workflow. It is initially empty when created by the work- 
flow agent 126-1. 

In the preferred embodiment, each of the clients w 
1 1 2 includes a processor 1 60 and a memory 1 62 (a fast 
primary memory, a slower secondary memory, or both) 
on which an operating system 1 64, browser 1 66 and the 
downloaded workflow courier 11& are stored. The 
browser 166 is a program that is configured to display is 
the downloaded workflow courier 118 in a way that 
allows users to interact with the forms 128 that partially 
compose the workflow represented by the workflow 
courier 1 18. The browser 166 is also capable of down- 
loading and executing the programs 130 that are refer- so 
enced or embedded in the downloaded workflow courier 
1 18. As mentioned above, in the preferred embodiment 
the programs 130 are written in Java, thus the browser 
1 66 is a Web browser, such as HotJava Finally, at least 
some of the clients 112 are coupled to respective dis- 25 
play/input devices 1 13, which allow a user or users to 
interact with the workflow courier 1 18 once it has been 
downloaded from the server 110. 

Referring to Figure 3, there is shown a flowchart 
illustrating how the workflow courier 118 enables the 30 
distributed, asynchronous execution of a workflow in a 
network environment. In the preferred embodiment, a 
user of a client 112-1 initiates a workflow by issuing a 
workflow request 1 16 to a server 110-1 that is responsi- 
ble for the execution of the workflow (210). This work- 35 
flow request 116 couid be explicitly entered by the user 
from the input device 113-1 or selected from a list of 
workflow options presented by the client 112-1 on the 
display 113-1. For example, in the travel request exam- 
ple from above, the workflow request 1 1 6 might be the 40 
HTTP equivalent of "client 112-1 requests initiation of 
travel workflow by the server 110-1." 

Upon receiving this workflow request 1 1 6, the work- 
flow agent 126-1 running on the server 1 10-1 builds the 
workflow courier 118-1, which, as mentioned above, 45 
embodies the forms 1 28- 1 , state information 1 32- 1 , pro- 
grams 130-1, and a registry 134-1 needed by the clients 
to perform the stages of the workflow initiated by the 
user 111-1 (212). The workflow agent 126 obtains this 
information from the workflow database 114-1, which so 
represents, for multiple workflows 140, the relevant 
forms 142, underlying rules 146 (e.g., who must 
approve what requests, the format of data fields in the 
forms, what data fields must be competed and meta- 
rules that describe the flow at a high level), and code 55 
fragments 144 that," when executed on a client 112, 
assist the actor using the receiving client 1 12 to com- 
plete a workflow stage. 

Once it has built the workflow courier 118-1, the 



workflow agent 126-1 transmits (i.e., using e-mail, RPC, 
HTTP, etc., ) the workflow courier 118-1 to a client 112- 
1 having an associated user who is the actor authorized 
to perform the first stage of the workflow (this actor is 
typically the requestor) (214). The actor then performs 
the first stage by filling in appropriate fields of the forms 
128-1 under control of the programs 130-1, which are 
executed by the client 112-1 while the first stage is 
being performed (216). For the purposes of this docu- 
ment, the actions performed in step (216) shall be 
referred to by the term "executing the workflow courier." 
After the user completes the first stage, the courier 1 18 
updates itself (218) (i.e., the forms and state informa- 
tion) and then determines whether the workflow has 
been completed (220). If the workflow has not been 
completed (220-NO), the workflow courier 118-1 trans- 
mits itself as the updated workflow courier 118-1" (Fig. 
1) to the client of the actor who is authorized to perform 
the next stage of the workflow and optionally sends a 
status update 1 1 7 (Fig. 1) to the database server (222). 
Once the workflow courier 1 1 8-1 ' is received by the next 
client, the same steps (216-222) are repeated until the 
last stage of the workflow is executed (220-YES), at 
which point the completed workflow courier 1 18 takes 
any final actions, including transmitting final notification 
to the database server 110-1 that kicked-off the work- 
flow (224). The completed forms 128 could also be 
transmitted back to the server 110-1, retained at the last 
actor's client 110 or transmitted to some other data 
repository. 

Having described the basic components of the pre- 
ferred embodiment and the method of the present 
invention, the components of the workflow courier 118 
are now described in greater detail. 

WORKFLOW COURIER 

Referring to Figure 4, there is shown a data-struc- 
ture oriented view of the workflow courier document 1 1 8 
of the present invention. As mentioned above in refer- 
ence to Figures 2 and 3, a workflow courier document 
1 18 is assembled by a server 1 10 in its primary or sec- 
ondary memory 122 in response to a workflow request 
1 1 6 issued from a client 1 1 2 by a user of that client 1 1 2. 
A copy of the workflow courier 1 1 8 is downloaded to the 
memory 162 of a first client (e.g, the client 112-1 (Fig. 
1)) that is to complete the first stage of the workflow. 
The copy of the workflow courier 1 18 is then updated 
and stored (as updated workflow couriers 1 18' and 118" 
(Fig. 1)) in the memories of other clients 1 12 (1 12-2 and 
112-3, respectively (Fig. 1)) as the stages of the work- 
flow are completed. As shown in Figure 4, each work- 
flow courier 118 includes a plurality of data structures, 
including forms 128, programs 130, accumulated state 
information 132. and a registry 134. Note that Figure 4 
shows the workflow courier 118 after it has been down- 
loaded to the memory 162-1 of the client 112-1 and 
before any actions have been taken by the first actor. 
The information in the data structures of Figure 4 repre- 
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sent hypothetical values drawn from the requested 
workflow 140-1 (i.e., the travel request workflow) dis- 
cussed above. 

The forms data structure 1 28 represents the form or 
forms that must be filled out in the course of the 
requested workflow 140-1. In the preferred embodi- 
ment, each form 128-i in the forms data structure 128 
includes header information 310-i and fields 312-ij 
(where i and j represent different indices) that corre- 
spond to the fields that must be f illed-in for the workflow 
to be completed. In Fig. 4, the forms data structure 128 
includes two forms 128-1 and 128-2, each of which has 
multiple fields, 312-1a, 312-1b, 312-1c and 312-2a, 
312-2b, 312-2c, 312-2d, respectively. 

The header 310-i defines the overall format in which 
a form 128-i is represented (e.g., whether the form is 
represented as an HTML document, a proprietary for- 
mat such as Delrina Forms, or a Postscript file, just to 
name a few possibilities) and, optionally, the URL (uni- 
versal resource locator) of the handler that is adapted to 
display the form on the client 112. For example, in Fig- 
ure 4, the form 128-2 (Form 1), which is in Postscript 
("Post") format, requires a Postscript handler whose 
URL is given by the CF3_ref entry of the registry 134. 
The handler information is sometimes optional as A 
could be implied by the format associated with a partic- 
ular form 128-i. This is because a Java-enabled browser 
166-1 can be configured to fetch from the network a 
handler based on the format of a particular form or doc- 
ument if a compatible handler is not already resident on 
the client where the form or document is to be. proc- 
essed. Note that the file format does not necessary 
mean that the file handler will be able to display all of the 
fields 31 2-i that compose the form. This is because indi- 
vidual fields 312-i can be in different formats - e.g., dif- 
ferent graphical formats - from the form in which they 
are embedded. This is consistent with the design of 
Java documents, where an HTML compound document 
can have embedded flat files with attributes that can 
only be displayed by handlers that are referenced by the 
flat file or which are implied by the attributes of the flat 
file. 

In the preferred embodiment, one of the forms 128 
is a master file 128-1 ("Master"), which, a client 112 
automatically displays 112 upon receiving a workflow 
courier document 118. This is possible as the master 
file 128-1 is always formatted as an HTML/Java docu- 
ment, which can be displayed by each of the clients 112. 
As with any top-level Java compound document, the 
master file 128-1 serves as a common starting docu- 
ment/form for each of the stages. 

Each of the fields 312-ij of a form 128-i includes a 
datum or data 320 and a pointer 322 to a code fragment 
reference (e.g., "*CF2_ref"). A datum 320 holds infor- 
mation entered by an actor or one of the programs 130 
in the field. This information is retained as the workflow 
is being executed. Note that, as Figure 4 shows the 
workflow courier 118-1 before any actions have been 
taken, the data 320 are all blank. 
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A CF_ref pointer 322-i stores the address of an 
entry in the registry 1 34 that contains a pointer to a pro- 
gram 130 that is associated with the corresponding field 
312-i (i.e., each field 312 is indirectly associated with a 
5 program via the registry 134). As mentioned above, a 
program 1 30 might be a handler for data stored in a par- 
ticular field, a mini-expert system to assist an actor in 
filling in a field or a larger-scope expert system that is 
familiar with how the workflow should be executed. The 
io actual executable program 130 could be stored within 
the workflow courier in the program cache 130 or 
remotely from the client 1 12 or server 1 10 in which the 
workflow courier 1 18 is resident. For example, the pro- 
gram cache 130 includes four locally-stored programs, 
15 progs 1 , 2, 4, 6 corresponding respectively to programs 
130-1a to 130a-1d, which were initially stored on the 
server 110-1. The respective URLs of these programs. 
*prog1 . 2, 4, 6 are stored in the registry 134. The regis- 
try 134 also stores the URLs of remotely stored pro- 
grams, such as the program 130-2a, which are not 
downloaded to the client 1 12 from their respective serv- 
ers 1 1 0 as a part of the workflow courier 1 18. When, in 
the course of executing stages of the workflow, a remote 
program is needed, it is downloaded and then stored in 
the program cache 130 with the other programs. For 
example, in Figure 4, program 3 (130-2a) has been 
download to the program cache 130. When a remotely- 
stored program is downloaded, the program's pointer in 
the registry 134 is reset to downloaded program as 
shown by the line 135. This indirection provided by the 
registry 134 is useful as many of the fields are likely to 
require the same program (e.g., the fields 312-1a to 
3 12- 1c and 312-2d all reference program 1) and storing 
multiple local pointers 322 to the one registry entry that 
stores the full URL for a shared program is far more effi- 
cient than storing identical program URLs in each 
CF_ref pointer 322. 

The workflow courier 118 also includes an accumu- 
lated state database 132, which is updated by the pro- 
gram elements 130 of the workflow courier 1 18-1 as the 
stages of the workflow are completed. This enables the 
workflow courier 1 18 to retain its state as it is transmit- 
ted to and asynchronously processed by other clients, 
such as the clients 1 1 2-2 and 1 1 2-3 (Fig. 2). Then, as it 
is executed at each client, the workflow courier 1 18 con- 
sults its accumulated state 132 before determining 
which stage is to be executed. 

WORKFLOW COURIER PROCESSING METHOD 

Referring to Figure 5, there is shown a flowchart of 
the method by which the present invention executes one 
stage of a workflow. The steps of this flowchart begin 
after the workflow courier 1 18 has been transmitted to a 
client 112 whose associated user is authorized to per- 
form one stage of the workflow. As the first step, the 
browser 166 running on the client 112 displays a stage- 
appropriate form 128-i, from which the user can select 
from among a number of basic options or fields to fill-in 
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(450). For example, this form could be a master form 
128-1 (Fig. 4) common to ail stages that includes three 
options, "Go", "Wait" and "Cancel", which an actor can 
select to indicate, respectively, his intention to execute 
the appropriate stage, perform the stage later, or refuse 5 
to perform the stage. 

Once the actor selects a field or option from the 
stage-appropriate form, the browser 166 fetches and 
executes the program linked to the selected field (452). 
Note that the linked program could be stored on the cli- w 
ent 1 1 2 in the program cache 1 30 or on some other net- 
work node. For example, if the actor selects trie "Go" 
option from the master form 128-1 (Fig. 4), which has a 
linked code fragment reference pointer value of 
"*CF1_ref" (Ftg. 4), the browser 166-1 will follow the is 
pointer '"CFI-ref " to the "CF1_ref " entry in the registry 
134-1, which, in turn, addresses "progl" (the workflow 
expert 310-1a) in. the local program cache 130. The 
browser 166-1 will then load and execute the workflow 
expert 3 10-1 a. 20 

Once a program is executing, that program deter- 
mines, based on the rules it encapsulates and the accu- 
mulated state 132, the forms 128 and programs 130 ft 
needs access to accomplish its task. The executing pro- 
gram then determines whether it has local access to all 25 
of those necessary forms 128 and programs 130. If not 
(454-NO), the executing program causes the browser 
166 to pull in from the network all of the needed docu- 
ments/forms and programs that are not locally available 
(456) and add those programs to the program cache 30 
130 or the forms database 128 in the workflow courier 
118 (458). When all of the necessary forms and pro- 
grams are locally available (454-YES), the executing 
program displays the necessary forms 1 28 and enables 
the actor to interact with (i.e., select and fill-in) appropri- 35 
ate fields of those forms under control of the program(s) 
linked to those fields (462). These linked programs can 
provide guidance as the actor fills in a respective field, 
check the information entered by an actor or determine, 
based on information entered by an actor, further nec- 40 
essary actions. For example, a linked program could 
advise the requestor in the travel request workflow to 
enter their desired travel dates in the MM/DD/YY format 
and also check all values entered by the requestor for 
conformity to that standard. 4S 

After the user interaction, the executing program, or 
one of the linked programs, updates the workflow cou- 
rier 1 1 8 and the displayed forms to reflect the latest user 
interaction and determines, again based on rules, 
whether the actor has completed the stage (460). If not so 
(460-NO), the executing program once again fetches 
and executes the program 130 linked to fields (if any) 
selected by the user in the most recent interaction 
(452). If the executing program determines that the 
actor has completed the stage (460-YES), the executing 55 
program updates the accumulated state 132 to show 
that the current stage has been completed and trans- 
mits the updated workflow courier 1 18 to a client with a 
user who is the actor authorized to perform the next 



stage of the workflow (464) . 

Prior to transmitting the updated workflow courier, 
as part of the state updating step, the local program 
cache 130 in the workflow courier is purged (A) of all 
programs that may not be needed by the next stage, or 
(B) all programs not designated as being a permanent 
part of the workflow courier, depending on the imple- 
mentation. 

In the preferred embodiment the identity of the 
authorized actor for the next stage is determined based, 
again, on rules. The rules could describe a static proc- 
ess for determining the next actor (e.g, "when done with 
stage 1 , send the updated workflow courier to request- 
ors manager: Bill Smith @ ###.com"). However, the 
workflow courier of the present invention is also able to 
resolve roles dynamically to an actor based on arbitrary 
criteria, which are defined in the rules). 

For example, in the travel request example, assume 
the following: 

(1) the workflow expert has a rule that says "once 
stage 1 is completed, forward the travel request to 
the requestor's manager for approval" (i.e., send 
the updated travel request to an actor whose actor 
type is "requestor manager"); 

(2) the workflow expert knows that the requestor 
has employee number 1, is an employee in depart- 
ment 1 and uses node 112-2; and 

(3) organizational information can be obtained from 
the user database 114-2, which is coupled to the 
database server 1 10-2 (see Fig. 2). 

Based on this information, the workflow expert 
would send the database server 1 10-2 a message ask- 
ing that server 110-2 to query the user database 114-2 
to determine the identity of employee 1's manager. 
Upon receiving the answer (e.g., "employee number 2 
@ network node 112-2"), the workflow expert would 
transmit the updated workflow courier 1 18-1" (Fig. 2) to 
that node, where the manager would be able to review 
the travel request. Of course, based on other rules, the 
meaning of the term "requestor's manager" could vary. 
For example, in the case of a local travel request, that 
term might mean the requestor's first level manager 
whereas, for an international travel request, the 
"requestor's manager" might be the second level man- 
ager. Thus, the workflow courier is able to resolve roles 
at runtime. 

Due .to the intelligence embodied in the programs 
130, other factors (i.e., other actor selection criteria) can 
be considered by the top-level program when forward- 
ing updated workflow couriers to other actors in the 
workflow after stages have been completed. For exam- 
ple, in a help desk application, calls received at one help 
desk after closing time could be relayed to a qualified 
individual at another office with later hours or in a differ- 
ent time zone. This information could be easily obtained 
from directories accessible to the workflow programs 
130. Alternatively, the nodes of the authorized actors 
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could be hard-coded in the workflow programs 130. 
This arrangement might be appropriate for simple work- 
flows that are always performed within a brief time 
frame or where all of the actors use clients connected to 
a single LAN. 5 

Having described the steps of the present inven- 
tion, a concrete example showing the application of 
these steps to the travel request workflow is now 
described in reference to Figure 6. 

Referring to Figure 6, there is shown a flow diagram io 
illustrating the interaction of the data structures of the 
workflow courier 118 and the network nodes 1 10, 1 12 
that perform the some of the stages of the workflow 
140-1 (i.e., the travel request workflow). In this diagram, 
data structures and display screens are shown as rec- is 
tangular boxes and the programs that operate on the 
data or display the screens are shown as diamonds. In 
many cases, the network node ID and the program ■ 
responsible for the illustrated step are shown as the pair 
host/program; e.g., "112/166" inside a diamond indi- 20 
cates that the step is performed by the browser 1 66 run- 
ning on the network client 112. Specifically, Figure 6 
illustrates the execution of the first stage of the workflow 
140-1 (i.e., the travel request workflow), where a master 
document ("Master") offers three options ("Go", "Wait" 25 
and "Cancel") and where another form ("Forml") 
requires a user to fill in their destination ("Dest", travel 
dates "Date", purpose for the travel ("Purp") and then, 
when they are finished, click on "Done." 

To initiate the workflow 140-1 , the requestor selects 30 
the travel request workf low option displayed on the dis- 
play/input device 113-1 that is coupled to the client 112- 
1. As a result the client 112-1 sends the travel request 
message 1 1 6 to the server 110-1. which builds and then 
transmits to the client 112-1 the workflow courier 118-1, 35 
which encompasses all of the forms and program refer- 
ences needed for the workflow 140-1 to be completed. 
Upon receiving the workflow courier 1 18-1 , the browser 
166 running on the client 112 displays the master form, 
which in HTML format, specifies three user-selectable 40 
options, "Go," which a user selects to proceed with the 
appropriate stage, "Wait," which a user selects to store 
the workflow courier 1 1 8 for later processing and "Can- 
cel," which, when selected, discontinues the workflow. 
In this example, the user selects "Go" and, as a result, 45 
the browser fetches and executes the workflow expert 
(progl), which is linked to the "Go" field via the *CF1_ref 
pointer to the CF1_ref entry in the registry 134. 

Program 130-1a (progl), the workflow expert for 
the workflow 1 40-1 . encompasses all knowledge about 50 
the order in which the stages of the workflow are to be 
executed and what forms and fields are to be completed 
in each stage. Based on the fact that the accumulated 
state 132 is empty, the workflow expert 130-1 a deter- 
mines that stage 1 needs to be completed and that this 55 
requires that Form 1 be filled out by the actor using the 
client 112-1. Consequently, the workflow expert 130-1a 
displays Form 1 on the display 113-1, with the assist- 
ance of the prog3 (a Postscript handler linked to the 



form 1). This form offers four selectable options, "Desti- 
nation?," asking the requestor to fill in their travel desti- 
nation, "Dates?," where the requestor enters their travel 
dates, "Purpose?." which asks the requestor to provide 
the purpose of the requested trip and "Done." which the 
requestor selects when they believe they have com- 
pleted the form. 

In the present example, the user first selects the 
"Dates?" field from the displayed Form 1. As a result, 
the workflow expert 130-a1 causes the browser 166 to 
fetch the program (i:e., prog4) linked to the date field. As 
mentioned above, this linked program might advise the 
requestor to enter their desired travel dates in the 
month/date/year, or MM/DD/YY, format and check all 
values entered by the requestor for conformity to that 
standard. Once prog4 determines the user has entered 
a conforming date, it enters that information in the 
appropriate field and format in the form 128-2 and 
returns control to the workflow expert. 

Assuming that the user has correctly filled in the 
appropriate forms, the user might then select the 
"Done." option. In the example shown in Figure 6, this 
option is linked to the workflow expert (progl) because, 
when this option is selected, the workflow expert 
(progl) must determine whether, according to its 
encapsulated rules whether the stage has been com- 
pleted by the requestor. Assuming that the user has cor- 
rectly completed the first stage, the workflow expert will 
update the accumulated state 132 to show that the first 
stage has been completed, determining the network 
node of the actor authorized to perform the next stage of 
the workflow and then transmit the updated courier to 
the that node. In this example, this means that the work- 
flow expert will ask the browser 166 to transmit the 
updated courier to the client 112-2, which is the network 
node associated with the requestor's manager. 

In one alternative embodiment of the present inven- 
tion, instead of presenting images to a standalone Web 
browser, the various programs 130 can be configured to 
provide data and forms as OLE objects so they can be 
used with applications and in any environments that 
support OLE object sharing (note: an OLE application 
can share data with and be embedded in other OLE 
applications, so that, for example, a user can insert a 
spreadsheet inside a word processor document and 
can edit the spreadsheet using the features of the 
spreadsheet program from within the embedding docu- 
ment by simply moving the cursor inside the spread- 
sheet window). In such a configuration, universally 
executable programs encapsulating business/workflow 
rules would be able to provide data for many common 
word processing, spreadsheet and database applica- 
tions. In a similar vein, the programs 130 can be modi- 
fied to support any variety of application program 
interfaces that might be the standard in the network 
environment in which the workflow is being performed. 
Of course, in every situation, all of the networked com- 
puters on which the workflow stages are to be per- 
formed must be able to process and execute the 
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programs that are embedded and/or referenced in the 
workflow courier. 

In another alternative embodiment, shown in Figure 
7, the workflow courier can be configured with a route 
510 and/or a rules 512 databases. The route database 
510 contains an ordered list of each of the stages and 
the nodes of actors authorized to perform those stages. 
The various workflow experts 130 would access the 
route 510 to determine the identity of the next actor to 
receive the updated workflow courier 118. This 
approach does lack some of the flexibility of the pre- 
ferred embodiment, but it also is less complex to imple- 
ment and is appropriate for workflows that are very 
straightforward. In this alternative embodiment, addi- 
tional flexibility could be provided by describing the roles 
of the authorized actors, where appropriate, and pro- 
vide the URL of an employee database where the node 
address of an authorized actor meeting that role can be 
found. For example, instead of specifying the route as: 



Stage 1 


employee num 321 


node 112-1 


Stage 2 


employee num 447 


node 112-2 


The route could be specified as: 


Stage 1 


employee num 321 


node 112-1 


Stage 2 


requestor manager 


dir. 114-2 @ 






node 110-2. 



The node information for the requestor manager 
indicates that the node and identity of the requestor's 
manager can be found in the directory 114-2, which is 
accessed through the database server 110-2. The rules 
database 512 is a copy of the workflow rules 146 that 
pertain to the initiated workflow. The programs 130 
would process these rules as needed. 

In yet another alternative embodiment, an abstract 
index (e.g, an index built around general concepts) in a 
database 1 14 is used to locate a list of specific names, 
each of which is bound to a specific object (e.g., a work- 
flow 140) that contains the rules, data structures, code 
references, etc., that pertain to one aspect of the 
indexed concept. This list of names is relumed to a 
user, who can then select one of the names, or a link to 
one of the names, at which point the reference is 
accessed and loaded. For example, the user could initi- 
ate a workflow by first submitting a very general query to 
a database server 110, such as "I'm interested in fish- 
ing". The server then scans its database 114 for fishing- 
related workflows and returns a document to the user 
listing the various options, for example: 



1) book a fishing vacation, 

2) order fishing tackle, 

3) buy a fishing boat, 

4) buy fishing clothes, etc. 

5 

Based on the user's selection of one or more of these 
options, the client 110 submits appropriate workflow 
request messages 1 16 and the server 110-2 builds and 
transmits the workflow courier 1 18 as described above. 

Claims 

1 . In a network that includes at least one server and at 
least one client coupled to said network, a compu- 

15 ter-readable memory associated with each of at 
least a subset of said at least one server and said at 
least one client, each said computer-readable 
memory being configured to direct an associated 
member of said subset to execute at least one 

20 stage of a plurality of stages that compose a work- 
flow and to cooperate with other members of said 
subset so that all of said stages of said workflow are 
executed by said members, one of said computer- 
readable memories comprising: 

25 

data representing manifestations of a set of 
actions to be completed through the execution 
of at least one of said plurality of stages, each 
of said stages being executable by a respective 
30 authorized actor associated with one of said 

members; 

state data indicating executed stages in said 
workflow; and 

a registry containing at least one code frag- 
35 ment reference that points to an executable 

code fragment stored on said network, each of 
said executable code fragments being executa- 
ble on any of said members; such that, when 
being executed on one of said members, an 
40 appropriate subset of said executable code 

fragments directs said one member to perform 
workflow tasks associated with an appropriate 
stage of said workflow based on actions of said 
actor, said state data and said data represent- 
45 ing manifestations and then updates said man- 

ifestations and said state data to indicate 
execution of said appropriate stage. 

2. The memory of claim 1, wherein said executable 
so code fragments are written in a platform-independ- 
ent computer language, each of said members fur- 
ther comprising a browser that is configured to load 
and run said executable code fragments. 

55 3. The memory of claim 1, wherein said code frag- 
ments incorporate a set of workflow rules defining 
how said stages are to be executed. 

4. The memory of claim 2, wherein, based on said 
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updated manifestations, said updated state data, 
said actions and said workflow rules, said subset of 
executable code fragments determines a subse- 
quent stage of said workflow to be executed and an 
actor type authorized to execute said subsequent s 
stage. 

5. The memory of claim 4, further comprising: 

an actor index comprising at least one network w 
reference to respective actor directories, 
wherein an actor directory includes addresses 
of network nodes associated with authorized 
actors; 

such that, following said determination of said is 
subsequent stage of said workflow to be exe- 
cuted and said actor type authorized to execute 
said subsequent stage, said executing subset 
directs said one member to access said refer- 
enced actor directories and select from said 20 
actor directories as an appropriate member for 
the execution of said subsequent stage a net- 
work node of an actor represented therein as 
having said actor type; said executing subset 
thereafter directing said one member to com- 25 
municate to said appropriate member said 
rules, said code references, said updated man- 
ifestations, and said updated state data so that 
said memory of said appropriate member can 
be configured to direct said appropriate mem- 30 
ber to execute said subsequent stage. 

6. The memory of claim 2, further comprising: 

a route defining a sequence of said stages and 35 
associating with each stage in said sequence a 
network node identifier of one of said members 
associated with an actor authorized to execute 
that stage; 

40 

wherein, following execution of one of said 
stages and based on said updated state data and 
said route, said subset of executable code frag- 
ments determines a subsequent stage to be exe- 
cuted and directs said one member to 45 
communicate to said actor authorized to execute 
said stage said route, said code references, said 
updated manifestations and said updated state 
data so that said memory of said appropriate mem- 
ber can be configured to direct said appropriate 50 
member to execute said subsequent stage. 

7. The memory of claim 2, wherein said data repre- 
senting said manifestations comprise a set of forms 

to be completed through the execution of said plu- 55 
rality of stages that compose said workflow; said 
executing subset of code fragments directing said 
member to display appropriate ones of said set of 
forms and enable actor interaction with said forms. 



8. A computer system for asynchronously executing 
steps of a sequential process on a network that 
includes at least one server and at least one client 
coupled to said network, said servers and said cli- 
ents each including a processor and a memory and 
having a unique network ID, said computer system 
comprising; 

a requestor that is executable on a client's 
processor, said requestor being configured to 
control messages issued by said client on said 
network, said messages including a request 
message instructing a particular one of said 
servers to transmit to said client a workflow 
courier requested by a user of said client; 
a provider that is executable on a server's proc- 
essor, said provider being configured to be 
responsive to said messages directed to said 
server, said provider being configured to 
respond to said request message by causing 
said server to transmit to said client said work- 
flow courier; 

said workflow courier comprising: 

a set of forms to be completed through the 
execution of a plurality of stages that com- 
pose a workflow, each of said stages being 
executable by a respective actor; 
state data indicating executed stages in 
said workflow; and 

a registry containing at least one code 
fragment reference, each of which points 
to an executable code fragment; 

such that, upon receiving said workflow courier 
over said network, said client displays one of 
said forms and, based on user interaction with 
said form and other displayed forms, selectably 
loads and runs a set of referenced code frag- 
ments that are configured, when running, to 
perform one or more of a number of workflow 
tasks, including displaying said forms, deter- 
mining from said state data a pending stage to 
be executed, guiding an actor through execu- 
tion of said pending stage based on workflow 
rules and updating said forms and said state 
data in said workflow courier to reflect comple- 
tion of said pending stage. 

9. The computer system of claim 8, wherein said exe- 
cutable code fragments are written in a platform- 
independent computer language, said clients fur- 
ther comprising a browser that is conf igured to load 
and run said executable code fragments. 

10. The computer system of claim 9, wherein said pro- 
vider is also configured to respond to broad user 
workflow requests issued from said requestor by 
providing said requestor with a plurality of workflow 
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options that satisfy search terms included in said 
broad user workflow request, each of said workflow 
options being linked to a specific workflow so that, 
when said user selects one of said plurality of work- 
flow options, said requestor is configured to issue s 
on said network a workflow request for said linked 
workflow. 

11- A computer-implemented method for performing 
workflow on a network comprising the steps of: 10 

(1) issuing a workflow request on said network; 

(2) in response to said workflow request, a 
server building a workflow courier, said work- 
flow courier comprising: 15 

(a) a set of data representing manifesta- 
tions of a set of actions to be completed 
through the execution of at least one of a 
plurality of stages that compose said work- 20 
flow, each of said stages being executable 

by a respective actor; 

(b) state data indicating executed stages in 
said workflow; and 

(d) a registry containing at least one code 25 
fragment reference, each of which points 
to an executable code fragment, each of 
said executable code fragments being exe- 
cutable on any of said nodes without com- 
promising integrity and security of said any 30 
node; 



displaying at least a subset of said set of data 
representing manifestations; 
based on user interaction with said displayed 
subset, selectably loading and running a set of 
referenced code fragments; 
said referenced code fragments, when running, 
performing one or more of a number of work- 
flow tasks comprising: 

displaying said set of data representing 
manifestations of a set of actions, 
determining from said state data a pending 
stage to be executed; 
guiding an actor through execution of said 
pending stage based on workflow rules; 
updating said set of data representing 
manifestations of a set of actions and said 
state data in said workflow courier to 
reflect completion of said pending stage; 
and 

forwarding updated workflow courier to an 
appropriate network node for execution of 
a subsequent stage by another actor. 



(3) said server transmitting said workflow cou- 
rier to a selected network node associated with 
an actor authorized to perform, in accordance 35 
with said workflow courier, an appropriate 
stage of said workflow. 

12. The computer-implemented method of claim 11, 
further comprising the steps of : ' 40 

(1) upon receiving said workflow courier over 
said network, said selected network node exe- 
cuting said workflow courier so that said actor 
performs said appropriate stage under control 4s 
of said executing workflow courier, said work- 
flow courier ensuring that said actor performs 
said stage according to said set of data repre- 
senting manifestations, said state data and 
workflow rules that define how said stages are so 
to be executed; and 

(2) upon completion of said appropriate stage, 
said workflow courier updating itself to reflect 
status of said workflow upon completion of said 
appropriate stage. 55 

13. The computer-implemented method of claim 12, 
wherein said step of executing said workflow cou- 
rier comprises: 
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(54) Distributed asynchronous workflow system and method 



(57) A system and method for automating workflow 
by distributing the tasks required for the execution of 
said workflow over servers and clients connected on a 
network. The disclosed system and method allow the 
stages of the workflow to be performed asynchronously, 
meaning that, once a workflow initiated by a user has 
been initiated by a database server, the stages of the 
workflow can be executed on respective network clients 
without further interaction with the server (i.e., without 
requiring a stateful connection between the clients and 
servers). This is accomplished through the use of a 
workflow courier that embodies all programs (encom- 
passing rules governing the execution of the workflow) 
and forms needed by clients to complete stages of the 
workflow. The workflow courier also stores workflow 
state information that indicates which stages of the 
workflow have been completed. The executable pro- 
grams are written in the platform-independent Java pro- 
gramming language and are therefore executable on 
any computer that has an installed Java browser. After 
each stage is executed, the client executing that stage 
updates the workflow courier and transmits the updated 
workflow courier to a client having an associated user 
Qfy who is authorized to perform the next step in the work- 
^ flow. The updated state information indicates to the 
l^j recipient of the workflow which stages remain to be 
CO completed. 
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